Creating a Schedule
Wherever possible, operational tasks should be automated. In , you can do this by creating schedules for processes, jobs and probes.
When assembling a production schedule, consider the following:
- What is coming into CMP from third parties and how often?
- What is produced by CMP for third parties and how often?
- What sort of alerts are required?
- Will it be necessary to monitor all stages of a process, for example batch, extraction, transformation and transmission?
- What sort of Service Level Agreements (SLAs) are required?
- Are exclusion calendars necessary? For example, does not accept files on non-banking days, which impacts the Mandate Registrations job.
- Which jobs must run constantly throughout the day, such as Workflow Monitor, for example?
It is recommend that start times for jobs are not scheduled between the hours of the morning when daylight savings changes occur in your locale because the time shift can cause a job to be skipped or repeated depending on whether the time moves back or jumps forward.
Operations for inbound files involve the following:
- A load polling for new files.
- A job being triggered if a file is successfully loaded.
- An acknowledgement daemon that informs the that CMP has processed the file; or whether there are issues with the file.
- Probes.
Scheduling considerations for inbound files include the following:
-
What is scheduled?
Daemons and jobs are triggered by the presence of an inbound file, so these cannot be scheduled.
-
Should probes be scheduled?
Daemons and jobs are not scheduled, but probes can be scheduled based on the frequency of the inbound files.
-
Why are probes required?
- To alert operators if no files are presented by the third party.
- To alert operators if files are loaded but have errors. Some errors may be fixable, but some not.
- To gather information about a job. For example an SLA can be that a file cannot contain more that a configurable amount of errors.
Triggered jobs are jobs that are initiated by the presence of a record in a particular state in a table. These include jobs such as Workflow Monitor, Action Monitor, Email Monitor and Ledger Monitor.
Scheduling considerations for triggered jobs include the following:
-
What is scheduled?
All jobs are triggered by the presence of a record in a table, so they cannot be scheduled.
-
Should probes be scheduled?
Probes are needed to check whether the triggered jobs are functioning as expected, so they can be scheduled to run every 10 minutes, for example.
- Why are probes required?
- To alert operators if there is a build up of errors, for example workflows all ending in a processing error. This type of is monitoring for normal execution of the job.
- To alert operators if a backlog of requests is building up, for example ledger transaction entries in a New state. This type of probe is monitoring for punctual execution of the job.
A process is a business operation consisting of one or more jobs and alerts(s) executed in sequence. The end goal of a process is typically a file for a third party. A process can also include extraction, transformation, transmission and acknowledgement daemons.
-
What is scheduled?
The process itself is scheduled. Jobs are executed in sequential order once the first job ends.
-
Should probes be scheduled?
Probes can be linked to the process to check whether a job executed as expected. However, probe scheduling can also take into downstream activity. For example, the Bill Print job is the final job in the Billing process. The output of the job is entries in the interface tables. Various daemons are then executed to get the billing batch to the third party. Probes should be scheduled for this.
-
Why are probes required?
- To alert operators if no file was presented to the third party.
- To gather SLA information. For example, the SLA for the Billing process is to produce a file for the print bureau. If no file is produced, the SLA is breached.
For an example of a production schedule, see Appendix A: Sample Production Schedule.
Related Topics